I like the idea of the web application firewall, and that looks like something that can setup on the same VM as what would be running Nextcloud, etc.

@jaredbusch said in Backup server - Software layout:

I use teams, even if there is only one NIC in the team most of the time, because I can add and remove NICs without impacting the higher layers.

Good idea. This server I just got has the onboard GB NICs, but also 2 dual port Intel GB NICs as well. I could create a BIG team if I wanted.

@brandon220 said in Network in industrial environments:

I installed a few of the wall racks with filters on the bottom and fans on top for exhaust like the ones Jared mentioned. Don't remember the brand or price. The equipment stayed very clean and cool. Hard part is remembering to change/clean the filters regularly depending on the environment.

That is what calendar events are for.

Now as a general recommendation (really never do this), don't install Windows Server onto the bare metal, install your hypervisor to the bare metal. In this case Hyper-V.

Apply your licensing to the 2 VM's that you are allowed to create with Standard (and up licensing) then you'll be allowed to move your VM's around every 90 days or sooner for hardware failures etc.

@BRRABill said in Never Install Hyper-V as a Role:

@scottalanmiller

If you went into a one physical server shop with Hyper-V installed as a role and existing VMs in place, would you consider this a big enough problem to redo the entire installation?

Immediately? No. But it would be immediately added to the project list to get planned as soon as convenient.

Step One: Install something other than Windows Home
Step Two: Be more secure

@Dashrender said in Windows DNS best practice:

@wirestyle22 said in Windows DNS best practice:

@Mike-Davis He is actually asking this in regards to my network. We have one root domain with two subdomains, all on their own subnets. How mine differs from the OP is both the primary and secondary DNS are in the main building attached to the root domain. We only use static IP's. There is no DHCP here. We don not even use wireless, although that will change in the near future.

What Wire didn't mention is that all servers and all clients in the entire organization use those two DNS servers at headquarters. That seems very odd to me.

FYI - Wire just came on with that client, so he didn't set this up.

This is correct

Adding in @HPEStorageGuy as we were discussing this exact topic a few minute ago on SW in another thread.

@Dashrender said in XenServer 7: best practice: noob question:

@scottalanmiller said in XenServer 7: best practice: noob question:

@Dashrender said in XenServer 7: best practice: noob question:

@scottalanmiller said in XenServer 7: best practice: noob question:

@DustinB3403 said in XenServer 7: best practice: noob question:

@FATeknollogee said in XenServer 7: best practice: noob question:

@DustinB3403

Does it have better performance & is it easier to setup?

That is all dependent on how comfortable you are with software / hardware raid.

Even for software RAID experts, hardware RAID is easier.

well yeah - it's practically plug and play - so few options.

Plus, in hardware RAID (assuming the chassis supports it) you get hot swap, something you don't get with Software RAID.

All enterprise software RAID has hot swap and always has. Only FakeRAID doesn't offer that and even that sometimes does. Hot swap is basically ubiquitous. Even ridiculous Windows software RAID has hot swap.

excuse me, I used the wrong term - I meant Blind swap - the lack of need to tell the OS to demount the drive before you pull it from the system.

Yes, now that software RAID generally lacks.

@Dashrender said:

Most storage devices in this range also lack the support options that enterprise servers do.

This sentence is the third italicized block of text seems odd.

Fixed, thanks.

thanks, fixed.

@Brett Depending on what FFL or DFL you are on, you won't even be able to use GPP to create a user because of the lack of password access in newer versions. I tried and it wouldn't work because I had to have a password per the policy but I couldn't add one per the change in GPP. The workaround was a script that I have for new machines that adds a local account via GPO startup script then adds it to the local administrators group. The new PC stays in a temporary OU for a few things to be installed, then moved to the permanent OU where the remaining items are run, including the installation of LAPS, which then changes the newly-created local admin password.

Here is the bat file that is called in the startup:

net user "My Admin" mypassword /add /passwordreq:yes /fullname:"My Admin"
net localgroup Administrators "My Admin" /add

Tab Mix Plus

Just realized that this topic actually was missing the tags! Ugh, no wonder if rarely comes up in searches. Fixed, finally.

@g.jacobse said:

I rant that over in my mind, and it seemed that if the reboot failed, you would not get any type of email.

If the reboot failed to run completely (like the system was down, cron had crashed, things were frozen) you would get no email either. You are making the system report on itself with is not good.

That's why the system should reboot itself (no way around that) but the monitoring of whether it is up or not should be done externally.

Great example came in today. Someone had a Dell server, four matching drives. The system arrived with no virtualization configured and the OS was installed without RAID on a single drive. Each drive was attached as an individual drive. Obviously Dell never intended someone to use the system like that, even for a desktop that's not an acceptable setup. It's pretty clear that it was just a test install to show that the hardware was working.

But several people said "but Dell set it up this way, obviously it is okay" and it has been running in production and is now a disaster.

@scottalanmiller said in Over documentation:

@Minion-Queen said in Over documentation:

The idea of creating the document to help you build out your documentation in theory should be a one time thing... As the management side of things I would say that there is hardly ever a case where too much documentation is an issue. All documentation should be done on the theory of "what if I get hit by a bus today?" can someone else step into my position seamlessly and the client not see any lag?

Too much documentation, though, can result in people being unable to find what is needed and the time needed to maintain it can become a point of inefficiency. And the more that there is, the more likely that it will go out of date and become a negative rather than a positive. Only good documentation is useful, and the more documentation you have, the higher chances that some of it will not be maintained.

We had an old guy that would "document" everything. He had tons of binders full of stuff and his home directory was huge with "documentation." His documentation was he would make a tiny note and then run a command and copy the output. That's pretty much all his notes were spanning back to ~2004-2005. He left and we ended up throwing it all away because we couldn't find anything useful at all.